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(54) Billing method on a pay per use basis for feature activations in a telephone terminal 
equipment 



(57) Activities in an interactive subscriber telephone 
terminal including incoming and outgoing calls and in- 
cluding services such as Call Display are counted and 



stored in a memory in the terminal. The terminal may be 
queried by a remote server to cause the stored number 
to be transmitted to the remote server for billing, man- 
agement or other purposes. 
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Description 

Field of the Invention 

This invention relates to telephone subscriber ter- 5 
minals of the type having a display screen and softkeys 
which are controlled by management software general- , 
ed-by a remote server. 

Background of the Invention io 

In December, 1.992 an industry-wide standard pro- 
tocol for Analog Display Services Interface (ADSI) was 
completed by Bell Communications Research Inc. (Bell- 
core specifications) to serve as a standard for voice and is 
display (data), information to be transmitted between 
subscriber display-based terminals and telecommuni- 
cations switches or servers over the existing copper tel- 
ephone lines. This standard protocol also defines the 
formats for the large scrollable displays and softkeys. to . 20 
support new enhanced, . interactive, services. 
, There is known an interactive subscriber terminal • 
ccmprising-a display screen, a plurality of temporarily 
definable response/data entry keys, and local control 
means for selectively causing said display screen and/ 2s 
or said response/data entry keys to be controlled by re- 
mote signals transmitted to the terminal from a tele- 
phone switching office or said local control means. 

. The known subscriber terminal has a relatively 
large scrollable display screen and context-sensitive 30 
softkeys which enable the terminal to make full 1 use of 
services typically provided by telephone operating com- 
panies, as well as those services provided by enhanced- 
service providers (ESP) delivering third party services 
and applications through the PSTN (public switched tel- 35 
ephone network). 

Enhanced service providers (ESPs) are the second 
major source of ADSI-based services. ESP applications 
are driven by information downloaded to the terminal 
from a server - for example, an interactive voice-respon- 40 
sive system located in a bank. 

The terminal supports the ADSI protocol which in- 
cludes the concept of FDM (feature download manage- 
ment) software scripts -which can control the display and 
the softkeys and cause the terminal to go on-hook, off- 45 
hook and dial numbers. The terminal also supports an 
extension to the Bellcore specifications which allows a 
server to download an FDM script without any interven- 
tion by the subscriber. This capability, called Server In- 
itiated Download or ADSI On-Hook Alerting for Automat- so 
ic Feature Download, requires access to the Ttp and 
Ring of the telephone line connected to the target sub- 
scriber terminal while the terminal is on-hook. The 
downloading of the FDM script is carried out unobtru- 
sively - i.e., without ringing the telephone. ss 

Billing for the use of features and services obtained 
via the FDM scripts is currently done by the Central Of- 
fice Switch of the PSTN which monitors feature access- 
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es and passes this information on to the telephone com- 

* pany billing system ' • • 

In. some cases it would be useful to allow a service 
provider that is not associated with the telephone com- 

- pany to bulk purchase features from the telephone com- 
pany for all their subscribers on a subscription basis and 
resell those services on a pay per use basis to the sub- 
scribers; thereby realizing a new revenue stream. This 
would require that the service provider have direct ac- 
cess to information relating to the use by each subscrib- 
er of ihe various billable features. 

Summary of the Invention 

It is an object of the present invention to provide a 
mechanism which stores information relating to various 
feature accesses and which permits communication of 
-this information to a remote service provider. 
^ To this end an interactive subscriber terminal as 
known is characterized by counter means for counting 
and storing the number of times the terminal engages 
in at least one predetermined activity. The activity could 
be anything occurring at the terminal such as an incom- 
ing call, an outgoing call, a busy signal or a feature or 
service such as Call Display or Call Return Busy. 

Brief Description of the Drawings 

Figure 1 is a block schematic of an ADSI subscriber 
terminal according to the present invention; 

Figure 2 is a pictorial drawing depicting the front of 
the subscriber terminal as accessed by a user; and 

Figures 3, 4 and 5 are flowcharts illustrating the 
process steps carried out by the software for FDM 
script commands, FDM script softkey return string 
commands and SDC (Server Display Control) com- 
mands, respectively. 

Detailed Description of the Preferred Embodiment 

Figure 1 of the drawings shows a block schematic 
of Analog Display Services Interface (ADSI) subscriber 
terminal 10, which comprises telephone (or terminal) 
base n and plug-in module 12. The base 11 connects 
to the TIP and RING of the telephone line connecting it 
to the centra! office (CO) of the telephone company. The 
base 11 comprises a line interface and electronic hook 
switch circuits 13, ring detector and alerter circuits 14, 
transducer interface and analog-to-digital (AID) convert- 
er circuits 15, processor interface and EEPROM circuits 
16, and standard touch-tone telephone keypad 17. A 
handset 18 is, of course, part of the standard telephone 
components of the base 11. The ADSI plug-in module 
12 comprises a data burst alert circuit 19, a microproc- 
essor 20, an LCD display driver 21 . an LCD display 22, 
softkeys (redefinable keys) 23 adjacent the display 22, 
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and a printer (or printer port tor an external printer) 24. 
Normally, the keys 23 will also include hard-keys such 
as scrolling cursor keys 25 and so on (as shown in Fig- 
ure 2). 

Reterring also to Figure 2, which shows the user- 
visible front of the ADSI terminal 10, the module 1 2 plugs 
into the base 1 1 and connects to the latter by means of 
two buses 26 and 27 : the former being the processor 
bus, and the latter for scanning the keys 23. The data 
burst alert 19, which comprises two switched-capacitor 
filters for detecting two pre-burst tones, receives signals 
through the interface 15 via connection 28. The sole 
function of the alert circuit 1 9 is to tell the processor 20 
by means of high -tone and low-tone leads 29 and 30 
that a data burst will follow. 

A calling line identifier device (GLID) 35 is also pro- 
vided in base 1 1 and a static RAM 36 and a non-volatile 
random access memory (NVRAM) 37 are provided in 
module 1 2 and connected to microprocessor 20. The 
NVRAM 37 contains a number of counters, one lor each 
FDM service script. Each counter would be required to 
be at least 2 bytes in length, for a maximum number of 
feature activations of 65,535 to be maintained by the 
CPE. For maximum flexibility there would be a large 
number of these counters. If thecounter number were 
specified by 1 byte this would allow 256 of these 
counters. This would require 256 * 2 = 51 2 bytes of non- 
volatile memory per FDM service script supported by the 
terminal. 

The software running the microprocessor includes 
instructions to increment, decrement or clear a particu- 
lar counter in response to a command associated, with 
a particular service or feature and also includes instruc- 
tions to query a particular counter on receipt of a "query", 
command. 

When a Server Initiated Download is instigated a 
remote server establishes connection through the 
PSTN with the subscriber terminal without ringing the 
telephone. This can be achieved as well known in the 
art by providing specialized connections from the server 
to the Central Office Switchtng.equipment. Alternatively, 
Server Initiated Download can be achieved without the 
specialized connections. More particularly: according to 
one aspect, the server calls up, the subscriber terminal 
and when there is a match between the server CLI D and 
a memory in the terminal in which a preselected set of 
CLIDS is stored, the Server Initiated Download protocol 
is followed. In another aspect the terminal automatically 
dials out at predetermined times to preselected servers 
and in a further aspect a pager in the terminal reacts to 
a preselected server to cause dial out to the server. 

. When connection is thus established between the 
server and the subscriber terminal, ADSI information 
(such as application and soft key definition data) is trans- 
mitted to the terminal at a rate of 1200 baud using the 
same type of signal that provided the calling line ID. The 
ADSI information can be transmitted as in-band signal- 
ling by previously transmitting two tones, 2130 Hz and 
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2750 Hz, simultaneously for 80 msecs which the data 
burst alert 19 recognizes as preceding a burst of ADSI 
information. Thus, the voice paths are muted during da- 
ta reception to ensure that data is not corrupted and that 
s the user will not hear data being transmitted. The two 
frequencies chosen can be isolated from voice because 
they are not among those generated by the dialpad and 
also do not occur frequently in conversation. 

These ADSI signals pass through the Line Interface 
10 and Electronic Hookswitch 13 : through the Transducer 
Interfaces and A/D Converter 15 where they are sam- 
pled and converted to digital signals by the A/D, through 
the Processor Interlace and EEPROM 16 which further 
processes the digital samples and then to the micro- 
's processor 20 which' is running S/W code contained in 
built-in masked ROM. The microprocessor 20 decodes 
the command and takes appropriate action on the RAM 
36 contained within the microprocessor block 20. Infor- 
mation to be sent back to the server originates Irom the 
20 microprocessor 20, is sent to the processor interlace 
- and EEPROM 1 6 and is then converted into DTMF (dual 
tone multi frequency) digits which are converted to an- 
alog waveforms by a D/A converter (not'shown) in Proc- 
. essor Interface block 16 which are then applied by the 
2S Transducer interfaces to Tip and Ring through the Line 
Interface and Electronic Hookswitch 13. 

The ADSI signals which are sent from the server to 
the subscriber terminal during Server Initiated Down- 
load are FDM script commands and the signals returned 
\30 from the subscriber terminal to the server are FDM script 
softkey return string commands. In order to support the 
. present- invention the ADSI protocol would have to be 
' extended to provide a new command added to existing 
■ FDM script softkey return string commands to cause a 
35 specified counter to be incremented, decremented, or 
cleared and a new command added to existing FDM 
script commands to cause a specified counter to be in- 
cremented, decremented, or cleared. 

An FDM script or an FDM script softkey return string 
to may represent a billable feature or service and the as- 
sociated command will cause the respective script 
counters in NVRAM 37 to be incremented when the 
FDM script or FDM script softkey return string is trans- 
mitted thereby counting the number of services provid- 
es ed. By way of example. Bell Canada makes available to 
subscribers a feature known as Busy Call Return either 
on a pay per use basis or on a subscription basis. This 
. feature allows a subscriber, when he/she calls a number 
and gets a busy signal, to be notified whenever that 
so number is free so that the call can then be redialled. Typ- 
ically, this feature is activated by the subscriber hanging 
up when the busy tone is received, waiting for dial tone 
and then dialling a specific code, currently *69. 

As an alternative on an ADSI telephone set a 
55 softkey could be presented by an FDM script on detec- 
tion of a busy signal such that pressing the softkey could 
cause the phone to go on-hook! wait 2 seconds, then 
go off -hook, wait for dial tone and dial the *69. Clearly, 
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the FDM script method is much easier for the consumer 
to use as only one softkey. has to be pressed and the 
rest follows automatically. 

Currently, the telephone company bills for this fea- 
ture by having software in the central office switch which 
counts the number of times that the feature is activated 
by dialling *69. Alternatively, according to the invention, 
the counting would occur in the terminal. This is partic- 
ularly well suited to an ADSI terminal which supports an 
ACMS (Advanced Call Management Services) FDM 
script, as it can detect call progress tones and automat-, 
ically put up softkeys to ACTIVATE various telephone 
company features with a single key press rather than 
the user having to remember the sequence usually re- 
quired to activate the feature. The invention encom- 
passes the idea of having the FDM.script softkey acti- 
vate the feature, AND count the number of times the fea- 
ture was activated in the phone, rather than in the central 
office switch. 

To support this concept, we need to have a com- 
mand as part of a softkey return string (which is the se- 
. „; quence cf commands that, are executed whenever a 
- . softkey is*pressed) which can increment a counter. In 
the example, the softkey that caused the phone to go 
on-hook, wait 2 seconds, go off-hook, wait for dial tone, 
dial *69 would also cause a specific counter to be incre- 
mented through the new command. 

We may also want to have some way of decrement- 
ing a counter if it subsequently turns out that the feature 
. was NOT available at the particular time the subscriber 
, tried to use it - thus the need for- a decrement counter 
. . command, both as part of. a softkey. return string AND 
as part of the generic script body. In the example say 
the user pressed the softkey to activate the feature, but 
then got back fast busy (which meant the service was 1 
not available). Upon detecting fast busy the counter 
would be decremented as the person had not really 
used the service and as such should not be billed for it. 

When the server and the subscriber terminal are en : 
gaged in an interactive session which is instigated after 
the subscriber lifts the telephone off-hook, this is known . 
as an SDC (Server Display Control) session. In order to 
support the present invention the ADSI protocol would 
have to be extended to provide a new command added 
to existing SDC commands to allow contents of a spec- 
ified counter for a specified FDM script to be queried 
and the value returned to the Billing System via encoded 
DTMF digits and a new command added to existing 
SDC commands to allow contents of a specified counter 
for a specified FDM script to be cleared. These two new 
SDC commands would have to be supported during 
Server Initiated Download mode. 

Thus, when the server wants to obtain billing infor- 
mation regarding a specified FDM script it sends the 
"Query" command and after the billing information has 
beep received it sends a "Clear" command to clear the 
counter. 

Specific examples of the new commands are listed 
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below. 

FDM Script Softkey Return String Commands 

5 Three new commands are required to support this 
feature. Suggested examples are given bebw but the 
actual codes used would have to be sanctioned by Bell- 
core. 

io Increment Counter XX = A1 XX in hexadecimal; 
Decrement Counter XX = A2 XX in hexadecimal; 
Clear Counter XX = A3 XX in hexadecimal; 

where XX is the counter number. 
75 These commandsiwould require the microproces- 
sor to interpret the softkey return string command, and 
adjust the specified counter in RAM as required. 

FDM Script Commands 

20 

Three new commands are required to support this 
feature. Again the examples given are merely sugges- 
tions. The actual codes used would be assigned by Bell- 
core. 

Increment Counter XX = OE XX in hexadecimal; 
Decrement Counter XX = OF XX in hexadecimal; 
Clear Counter XX = -10 XX in hexadecimal; 

where XX is the counter number. 
These commands would require the microproces- 
to interpret the script command, and adjust the spec- 
ified counter in RAM as required - 



One new command is required to support this fea- 

e: " ' ' 

; SDC Parameter Type = Query Counter = 153 dec- 
imal, 99 hexadecimal; for example or any other ap- 
: propriate single Byte number assigned by Bellcore 
"so as to uniquely identify this command 
Parameter Length = Number of bytes following = OA 
hexadecimal. 

Counter Number = 1 Byte = XX 
FDM# = 4 Bytes = Number of FDM Script for which 
counter value is to be queried. 
Security Code = 4 Bytes = Security Code for FDM 
script for which counter value is to be queried. 
Version Numbers 1 Byte- Version Number of FDM 
Script for which counter value is to be queried. 

If the requested FDM script is not loaded into the 
55 subscriber terminal, the terminal will return a DTMF A 
within 1 second. 

If the requested FDM script is loaded into the sub- 
scriber terminal, the terminal will return the two byte 
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counter contents LSB first using encoded DTMF fol- 
lowed by a 

DTMF B within 1 second. 
Note that this command needs to be supported dur- 
ing an SDC session, and during a Server Initiated Down- 
load so that counter values can be queried without any 
user intervention. 

SDC Clear Counter Commands 

One new command is required to support this fea- 
ture: 

SDC Parameter Type = Clear Counter = 154 deci- 
mal. 9A hexadecimal, for example or any other sin- 
gle byte number assigned by Bellcore so as to 
uniquely identity the command. 
Parameter Length = Number of bytes following = OA 
hexadecimal, v 
Counter Number = 1 Byte = XX. 
FDM# = 4 Bytes = Number of FDM Script for which . 
counter value is to be queried. 
Security Code = 4. Bytes - Security Code for FDM 
script for which counter value is to be queried. 
Version N umber = 1 Byte = Version Number of FDM 
Script for which counter value is to be queried. 

If the requested FDM script is not loaded into the 
subscriber terminal, the terminal will return a DTMF A 
within 1 second. 

If the requested FDM script is loaded into the sub- 
scriber terminal, the terminal will clear the specified 
counter to 00 and return a DTMF B within 1 second. 

Note that this command needs to be supported dur^ 
ing an SDC session and during a Server Initiated Down- 
load so that counter values can be queried without any 
user intervention. 

Although the operation of these new commands can 
be determined from the above description reference is 
now made to Figures 3, 4 and 5 which illustrate more 
explicitly the software process steps in which these new 
commands are used. Referring firstly to Figure 3,. which 
relates to the processing of FDM script commands, as 
an FDM event is processed the first decision that is 
made is whether the end of the event code has been 
reached. If "Yes", the process ends. If "No", the next in- 
struction YY is read and, if this instruction includes 0E, 
OF or 1 0 (increment counter, decrement counter or clear 
counter) the next byte is read. Thereafter, it is deter- 
mined which of the three (0E, OF or 10) is actually 
present and the counter incremented, decremented or 
cleared as appropriate. 

The process then steps back to the first decision 
block "End of Event Code?". If none of OE, OF or 10 is 
present in the second decision block "YY=0E, OF or 10? 
", then the usual processing steps for the FDM event are 
followed as indicated by the block "Process as per ex- 
isting". 



The process steps for the FDM softkey return string 
are illustrated in Figure 4 and these can be seen to be 
virtually identical to the process steps shown in Figure 
3. In this case, the inclusion of A1.A2 or A3 in the in- 
5 struction signifies increment counter, decrement coun- 
ter and clear counter, respectively. 

Turning to Figure 5. which illustrates the process 
steps for the SDC commands, the first decision block 
corresponds to the first decision block of Figures 3 and 

io 4 except that it queries "End of Commands" and if "No" 
the next parameter is read The next decision block de- 
termines if the parameter type is identified by 99 or 9A 
or by other digits. If 99 or 9A are present (indicating re- 
spectively the "Query Counter 0 and the "Clear Counter" 

'5 command), the parameter length is read and if this 
equals OA hexadecimal the counter number is read. 
Thereafter the FDM#, security code and the Version# 
are read and the third decision block determines wheth- 
er the FDM script specified by the FDM#, security code 

20 ■ and the Version* is present in the subscriber telephone. 
If they are present, the process goes on to read the 
counter if YY=99 or clear the counter if YY=9A. If the 
counter is read the counter contents are sent to the re- 
mote server. Alternatively, the counter will be cleared (if 

25 YY=9A). In both cases a DTMF Bis returned to the scrv- 
. er to indicate that the command was successful and has 
been completely processed. 

If either NN_0 A hexadecimal or the FDM#, security 
code or the Version# do not match an FDM script 

30 present in the telephone, a DTMF A is returned to the 
- server to indicate to the server that the command was 
. not completed successfully. The process is then looped 
. back to the first decision block to determine whether 
there are any more commands. 

35 Although in the embodiment described herein the 
counters are used to provide billing information, the 
counters could be used in other ways. For example, they 
could- be used simply to provide information about the 
number of times a particular feature or service was ac- 

^0 cessed whether or not the feature or service is billable. 
This information could be used for management or other 
purposes. Alternatively, the terminal could be arranged 
when a particular feature or service count exceeds a 
predetermined value to cause a specific action to be tak- 

45 en. As an example, suppose the counter used to count 
Busy Call Return activations has exceeded 12 since it 
was last cleared; this could trigger a screen to be dis- 
played informing the user IhatUhey would be billed the 
maximum for that month, and since they were such a 

50 frequent user it would be better for them to be on the 
subscription method of paying for the service (which re- 
sults in a more constant revenue stream for the tele- 
phone company). 

To enable this type of logic would require a new 

55 FDM event to be generated whenever a counter 
changed value - this event would be the trigger that 
could cause a screen to be displayed. For example, 
when the user pressed the Call Return Busy softkey for 
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the 12th time, an event would be generated that would 
contain information that the counter #xx= 1 2. A new com- 
mand within the script body itself would then trigger on 
counter #xx being = 1 2, and cause a screen to be shown. 
Note that the new script body command would also al- 
low different types of comparisons to be made before it 
would "match* - less than, equal to, greater than, less 
than or equal to, "greater than or equal to. This would 
provide flexibility to use the counters for almost anything 
within the script. . 



Claims 

1. An interactive subscriber telephone terminal com- 
prising a display screen, a plurality of temporarily 
definable response/data entry keys, and local con- 
trol means for selectively causing said display 
screen and/or said response/data entry keys to be 
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ties engaged in by a subscriber terminal, character- 
ized by: 

storing in a counter means in the terminal the 
5 number of times the activities are engaged in 

by the terminal, 

querying from the remote server the counter 
means, and 

transmitting to the remote server from the coun- 
7 <> " ter means information relating to the number of 

. .times contained in the counter means. 

9. A method according to claim 8, characterized in that 
the activities comprise the use of features or serv- 
es " ices. 
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controlled by remote signals, transmit) ed to the lerr. 20. . 
minal from a telephone switching office or said local 
control means, ^characterized by counter means for 
counting and storing the number ol times the termi- 
nal-engages in at least one predetermined activity. 

25 

2. A terminal according to claim 1 , characterized in 
that the at least one predetermined activity is at 
least one predetermined feature or service. 

3. A terminal according to claim 1 or claim 2, charac-, 30 ^ 
terized in that the counter means is responsivejo.a 
query signal from a remote server to transmit the 
stored number to the remote server. * 

4. A terminal according to ciaim 1, 2 or 3, character- 3$ 
ized in that the counter means is responsive to a 
clear signal from the remote server to clear the 
stored number. 

5. A terminal according to claim 2, characterized in *o 
that the predetermined feature cr service is provid- 
ed by means of a software script generated in the 
terminal or transmitted from a remote server. 

6. A terminal according to claim 5, characterized in 45 
that the software script has associated therewith a 
command causing the counter means to be incre- 
mented, decremented or cleared. 

7. A terminal according to any preceding claim, char- so 
acterized in that the counter means comprises a 
plurality of counters contained in a NVRAM each for 
counting and storing the number of times a corre- 
sponding predetermined activity is accessed by the 
terminal. ss 

8. A method of obtaining by a remote server through 
a telephone network information relating to activi- 
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